This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
The following abbreviations that may be found in the specification and/or the drawing figures are defined as follows:
ASIC application specific integrated circuit
DRTM dynamic root of trust measurement
HW hardware
IMA integrity measurement architecture
I/O input/output
IV initialization vector
MRTM mobile remote-owner trusted module
MTM mobile trusted module
OS operating system
PCR platform configuration register
RIM reference integrity metric
RTM root-of-trust for measurement
SW software
TCB trustee computing base
TCG trusted computing group
TPM trusted platform module
TrEE trusted execution environment
Reference with regard to MTM can be made to “Mobile Trusted Module (MTM)—an introduction”, Jan-Erik Ekberg, Markku Kylämpää, Nokia Research Center, NRC-TR-2007-105, Nov. 14, 2007.
The TPM specification (Trusted Computing Group. Trusted Platform Module (TPM) Main Specification. Version 1.2 Revision 103, 9 Jul. 2007, http://www.trustedcomputinggroup.org/resources/tpm_main_specification) previously introduced the “Dynamic Root of Trust” with the intent to support trusted hypervisors beneath operating systems. A hypervisor is basically a system program that provides a virtual machine environment. The main functionality of this specific feature is that an external, chip-dependent trigger resets a subset of the TPM PCRs, and launches code (residing in a temporarily secured memory location) into one of these PCRs. Thus, even if the machine had been running for some time when this event was triggered, there is a “fresh start” with respect to computation done by the measured code (assumed to be a hypervisor).
Over the last few years, the DRTM technology has in the research community found many further uses that do not relate to virtualization and hypervisors. Reference in this regard may be made to, for example, Jonathan M. McCune, Bryan J. Parno, Adrian Perrig, Michael K. Reiter, and Hiroshi Isozaki, “Flicker: An Execution Infrastructure for TCB Minimization”, in Eurosys >08: Proceedings of the 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems 2008, pages 315B328, New York, N.Y., USA, 2008. ACM. The concept that a code fragment can be securely measured (as well as its input and output) and executed in independence may be viewed as giving this system an aspect of a trusted execution environment (TrEE). Even without initializing a virtualization layer DRTM can be used within a single OS for credential calculations, secure storage, trusted I/O and other security features that are typically achieved using virtualization, external smart cards and processor secure environments such as ARM TrustZone.
DRTM as a concept combines isolation with a hardware-supported (PCR) reset functionality. The fact that the isolation is done by HW and not in SW has a major contribution to the achieved security level, although conceptually isolation can be achieved by either means. Thus, herein the concentration will be on state/PCR resetting.
The intermittent, so called “roller coaster use” of the DRTM is especially useful for services that have no, or a very weak relationship to the operating system state and/or state history. For example, assume that the user of a device needs to authenticate to a network or service, or needs to authorize a purchase. The service provider and even the device user may have no incentive to bind such a transaction to the device state, however at least the user has an incentive to protect the credential (and thus any related computation where, for example, a secret key takes part) used for authentication or authorization. The DRTM provides a well suited mechanism for this purpose. However, binding, for example, an OS mechanism to such a credential usage is unnecessary and most likely increases the complexity of such transactions.
Another class of services which benefit from DRTM relate to computer applications that typically by design are not persistent but rather launched and stopped at will, depending on the needs of the user. If such an application defines a system capability or feature worthy of attention, the traditional TPM approach can be crystallized by the OS adding TPM events/PCR updates on application launch/termination, producing a potentially infinitely long log of events that with the help of a complete TPM attestation can (in principle) be parsed to determine the current (application) state of the system. On the assumption that the OS has been securely booted or correctly measured in trusted boot, and serves as a measuring point (a part of the so called Root-of-Trust for Measurement (RTM)), the requirement that PCRs cannot be reset (for those PCRs that will denote application state in a given configuration) may be found to be unnecessary. DRTM has provided one (admittedly course-grained) solution for providing PCR resetting in the TPM domain.